1. Field of the Invention
The present invention relates to the field of network computing, and in particular to web content accessible via a portal and a method and respective system for sharing data between portlets within a portal.
2. Related Art
Portals provide end users with unified access to content, applications, and collaboration services in a highly personalized manner. An example is IBM's WebSphere Portal which provides a middleware framework and tools for building and managing portals using component applications called “portlets”.
FIG. 1 gives a schematic system view of a web server implementing a prior art portal.
A portal is typically implemented on a network server, for example a web server 100, which includes various logic components for user authentication 105, state handling 110, and aggregation 115 of fragments. The web server 100 further includes a plurality of portlets 120 provided in respective pages 125, with a respective plurality of APIs 130 to a respective portlet container software 135 for setting the pages 125 into a common web page context, and some portal storage resources 140. The logic components are operatively connected such that data can be exchanged between single components as required.
A portal engine of the web server 100 in FIG. 1 implements an aggregation of portlets 120 based on an underlying portal model 150 and portal information such as security settings, user roles, customization settings, and device capabilities. Within a rendered page 125, the portal automatically generates the appropriate set of navigation elements based on the portal model 150. The portal engine invokes portlets 120 during the aggregation as required and when required and uses caching to reduce the number of requests made to the portlets 120.
Web clients interact with portlets via a request/response paradigm implemented by the portal. Usually, users interact with content produced by portlets by, for example, following links or submitting forms, resulting in portlet actions being received by the portal, which are then forwarded to the portlets targeted by the user's interactions.
Prior art portals provide integration functionality which facilitates cooperative portlets that can be developed independently but can interact with one another and share the same information. Cooperative portlets exchange information, react in a coordinated manner and provide menus to share information by selecting an action.
For example, a property (one piece of information, for example, a department number) can be “published” by a department list viewer portlet and “consumed” by a target portlet displaying all employees from the selected department number or can be consumed by a portlet displaying detailed information of the selected department. In addition, the cooperative portlet technology also enables the broadcast of data to multiple portlets.
A prior art integration component as disclosed in US 2004/0243577 is, for example, implemented in an integration component 116 (FIG. 1). The integration component relies on portlets being producers and consumers of typed properties. Portlets can either register directly as consumers and producers of properties or indirectly via specific actions that consume and produce properties. The integration component facilitates interactions between portlets either by allowing the property produced by a portlet to be consumed by another portlet or by allowing a property produced by a portlet to trigger an action on another portlet. The integration component uses the types associated with properties to determine compatibility between properties belonging to different portlets.
The integration component may not by itself orchestrate the interactions between portlets. Instead, it allows portal users to manually direct interactions by presenting them with a pop-up menu to trigger any of the valid interactions. It also allows portal administrators to specify the automatic triggering of interactions with page definitions.
The integration component also allows a portal administrator to configure connections, or wires, between cooperative portlets. Properties are then exchanged automatically between connected portlets. Setting up wires between portlets allows to persistently save data transfer selection choices. The wire may be used to automatically transfer properties to target portlets when specific interactions are performed without displaying the pop-up menu prompting the user for more information.
Disadvantageously, this method is very inflexible for a portal user because the above mentioned wires between portlets typically are fixed for a user and can be configured by a portal administrator only. Thus, when an administrator has configured a wire between two portlets A and B on a portlet page, a user action in portlet A will trigger an action in portlet B, which in turn changes the internal persistent state of portlet B. Given a situation where the user wants to use portlet A but does not want to change the internal state of portlet B, and where the wiring between portlet A and portlet B is fixed and can be changed by an administrator only, the user cannot realize his intentions.